Sleep(0)
Otázka od: Aleš Kresta
10. 9. 2002 20:41
Dobry den
nekde jsem cetl ze je dobre obcas zavolat proceduru Sleep, treba i s
parametrem 0. A to z duvodu, ze se da trochu procesoroveho casu ostatnim
aplikacim, a ze dojde ke zpracovani udalosti a prekresleni zmen na formu.
Kdysi jste zde doporucovali taktez application.processmessages . Chtel bych
se zeptat jaky je v techto funkcich rozdil a kterou mam pouzit jestlize
zpracovavavm velke mnozstvi dat na pozadi windows a zaroven bych chtel na
tomto pocitaci i pracovat. Predem diky za osvetu
Odpovedá: Jakub Dusek
11. 9. 2002 18:46
To Thread.Terminated je tu samozrejme jen priklad, zrovna tak tam muze
byt jakykoliv boolean. Muj pripad nema s thready nic spolecneho, je to
zavadejici. Proste obecne, pokud mam cyklus, ktery nic nedela a jen
ceka a dam do nej Application.ProcessMessages tak aplikace zere 100%
procesoru. Bez Sleep.
Jakub Dusek
-------------------------------------------
Homepage : http://dusek.webz.cz
Phone : +420604615795
Sms email : jakub.dusek@click.cz
ICQ: 86063232
Apps : Add/Remove Manager, Charmaper,
Sms GateKeeper
-------------------------------------------
Wednesday, September 11, 2002, 4:14:18 PM, you wrote:
PV> From: "Jakub Dusek" <jdev@seznam.cz>
>> while not (Thread.Terminated) do
>> begin
>> Sleep(1);
>> Application.ProcessMessages;
>> end;
PV> Je naprosty nesmysl, protoze:
PV> - Application objekt existuje v hlavnim threadu a neni thread-safe
PV> - kazdy thread ma svoji vlastni frontu zprav
PV> - zpracovavat zpravy (a vubec nastartovat frontu zprav v thredu) neni v
99.9%
PV> pripadu vubec potreba
PV> Petr Vones
Odpovedá: Petr Vones
11. 9. 2002 2:16
From: "Aleš Kresta" <kresta.ales@seznam.cz>
> nekde jsem cetl ze je dobre obcas zavolat proceduru Sleep, treba i s
> parametrem 0. A to z duvodu, ze se da trochu procesoroveho casu ostatnim
Ne (alespon v tomto kontextu)
> aplikacim, a ze dojde ke zpracovani udalosti a prekresleni zmen na formu.
Ne.
> Kdysi jste zde doporucovali taktez application.processmessages . Chtel bych
Ne.
> se zeptat jaky je v techto funkcich rozdil a kterou mam pouzit jestlize
Ani jednu.
> zpracovavavm velke mnozstvi dat na pozadi windows a zaroven bych chtel na
> tomto pocitaci i pracovat. Predem diky za osvetu
Pokud jde o problem GUI (vykreslovani oken atd) tak kazda aplikace (presneji
receno thread) ma svoji frontu zprav, takze beh jedne aplikace nema vliv na
aplikace ostatni (maximalne ten, ze procesor je zpracovanim vice vytizen).
Pokud ma GUI reagovat behem nejake delsi akce v te aplikaci, tak je nejlepsim
resenim tuto akci provadet v samostatnem threadu a hlavni thread aplikace
ponechat ciste jen na graficke rozhrani a logiku aplikace.
Petr Vones
Odpovedá: David Mensik
11. 9. 2002 17:49
> Pokud jde o problem GUI (vykreslovani oken atd) tak kazda aplikace
(presneji
> receno thread) ma svoji frontu zprav, takze beh jedne aplikace nema vliv
na
> aplikace ostatni (maximalne ten, ze procesor je zpracovanim vice vytizen).
Mam dojem, ze nikoliv thread, ale aplikace (viz skryte delphacke okno
aplikace) ma svou frontu zprav (doufam 
.
> Pokud ma GUI reagovat behem nejake delsi akce v te aplikaci, tak je
nejlepsim
> resenim tuto akci provadet v samostatnem threadu a hlavni thread aplikace
> ponechat ciste jen na graficke rozhrani a logiku aplikace.
M$ tohle dlouho resil a vyresil to tak, ze jediny thread vykresluje -
ostatni nemuzou - duvody synchronizace apod... Nevim, jestli jde
vykreslovani okna aplikace explicitne presunout do jineho threadu...
Pokud se mylim, tak mne opravte.
Ozon
Odpovedá: Jakub Dusek
11. 9. 2002 13:45
Sleep(1) pouzivam v kombinaci s Application.ProcessMessages v
cyklu ktery na neco ceka a jinak nic nedela.
Pokud udelas treba:
while not (Thread.Terminated) do
Application.ProcessMessages;
tak stoupne vytizenost procesoru aplikaci na 100%, i kdyz aplikace
jinak nic nedela 
Kdezto:
while not (Thread.Terminated) do
begin
Sleep(1);
Application.ProcessMessages;
end;
funguje ok.
Jakub Dusek
-------------------------------------------
Homepage : http://dusek.webz.cz
Phone : +420604615795
Sms email : jakub.dusek@click.cz
ICQ: 86063232
Apps : Add/Remove Manager, Charmaper,
Sms GateKeeper
-------------------------------------------
Tuesday, September 10, 2002, 8:54:49 PM, you wrote:
AK> Dobry den
AK> nekde jsem cetl ze je dobre obcas zavolat proceduru Sleep, treba i s
AK> parametrem 0. A to z duvodu, ze se da trochu procesoroveho casu ostatnim
AK> aplikacim, a ze dojde ke zpracovani udalosti a prekresleni zmen na formu.
AK> Kdysi jste zde doporucovali taktez application.processmessages . Chtel bych
AK> se zeptat jaky je v techto funkcich rozdil a kterou mam pouzit jestlize
AK> zpracovavavm velke mnozstvi dat na pozadi windows a zaroven bych chtel na
AK> tomto pocitaci i pracovat. Predem diky za osvetu
Odpovedá: Petr Vones
11. 9. 2002 16:28
From: "Jakub Dusek" <jdev@seznam.cz>
> while not (Thread.Terminated) do
> begin
> Sleep(1);
> Application.ProcessMessages;
> end;
Je naprosty nesmysl, protoze:
- Application objekt existuje v hlavnim threadu a neni thread-safe
- kazdy thread ma svoji vlastni frontu zprav
- zpracovavat zpravy (a vubec nastartovat frontu zprav v thredu) neni v 99.9%
pripadu vubec potreba
Petr Vones
Odpovedá: Petr Vones
11. 9. 2002 18:04
From: "David Mensik" <mensikd@seznam.cz>
> Mam dojem, ze nikoliv thread, ale aplikace (viz skryte delphacke okno
> aplikace) ma svou frontu zprav (doufam .
Ne. Fronta zprav je vzdy vztazena k threadu, ne procesu. Pritom thread nemusi
mit zadnou frontu.
> M$ tohle dlouho resil a vyresil to tak, ze jediny thread vykresluje -
> ostatni nemuzou - duvody synchronizace apod... Nevim, jestli jde
> vykreslovani okna aplikace explicitne presunout do jineho threadu...
Neni treba nic presouvat (ani to neni dost dobre ve VCL mozne). Do jineho
threadu se prave presune ta akce.
Petr Vones
Odpovedá: David Mensik
12. 9. 2002 11:03
No, tak jsem po dlouhe dobe otevrel M$ API help
Frontu zprav ma asociovan thread, ktery vytvoril okno, jemuz je zprava
zasilana => ano, thread ma frontu zprav, ale pouze ten thread, ktery
vytvoril window... Takze neni pravda, ze kazdy thread ma frontu zprav (tak
jsem pochopil Vase tvrzeni ja).
Fronta zprav je tedy primarne vztazena nikoliv k threadu, ale k window
(pochopitelne funkce musi vykonavat thread - to ani nijak nejde... ;)).
Ozon
----- Original Message -----
> Ne. Fronta zprav je vzdy vztazena k threadu, ne procesu. Pritom thread
nemusi
> mit zadnou frontu.
Odpovedá: Erik Salaj
13. 9. 2002 7:35
> No, tak jsem po dlouhe dobe otevrel M$ API help
> Frontu zprav ma asociovan thread, ktery vytvoril okno, jemuz je zprava
> zasilana => ano, thread ma frontu zprav, ale pouze ten thread, ktery
> vytvoril window... Takze neni pravda, ze kazdy thread ma frontu zprav (tak
> jsem pochopil Vase tvrzeni ja).
> Fronta zprav je tedy primarne vztazena nikoliv k threadu, ale k window
> (pochopitelne funkce musi vykonavat thread - to ani nijak nejde... ;)).
to je logicke, ved naco by bola kazdemu threadu fronta sprav.
Erik
Odpovedá: Dalibor Toman
13. 9. 2002 7:45
> No, tak jsem po dlouhe dobe otevrel M$ API help
> Frontu zprav ma asociovan thread, ktery vytvoril okno, jemuz je
zprava
> zasilana => ano, thread ma frontu zprav, ale pouze ten thread, ktery
> vytvoril window... Takze neni pravda, ze kazdy thread ma frontu
zprav (tak
> jsem pochopil Vase tvrzeni ja).
> Fronta zprav je tedy primarne vztazena nikoliv k threadu, ale k
window
> (pochopitelne funkce musi vykonavat thread - to ani nijak nejde...
;)).
chyba. Fronta zprav nemusi mit nic spolecneho s oknem (ackoliv tomu
tak obvykle je).
Viz napoveda k funkci PostThreadMessage
D. Toman
Odpovedá: Petr Vones
13. 9. 2002 6:09
From: "David Mensik" <mensikd@seznam.cz>
> Frontu zprav ma asociovan thread, ktery vytvoril okno, jemuz je zprava
> zasilana => ano, thread ma frontu zprav, ale pouze ten thread, ktery
> vytvoril window... Takze neni pravda, ze kazdy thread ma frontu zprav (tak
> jsem pochopil Vase tvrzeni ja).
Frontu zprav ma ten thread, ktery poprve zavolal nejakou funkci z User nebo
Gdi, neni dulezite jestli v tom threadu bylo zaroven vytvoreno okno nebo ne.
Jak jsem psal, thread frontu zprav mit samozrejme nemusi, pokud nebyla splnena
podminka vyse.
> Fronta zprav je tedy primarne vztazena nikoliv k threadu, ale k window
Ne. Jeden thread muze mit nekolik oken, zatimco okno muze patrit pouze jednomu
threadu.
Petr Vones
Odpovedá: David Mensik
13. 9. 2002 13:24
OK...
Vy mate pravdu a ja jsem se mylil.
Je to tak, thread ma svou frontu zprav. Sorry, mlzim.
Ozon
----- Original Message -----
> chyba. Fronta zprav nemusi mit nic spolecneho s oknem (ackoliv tomu
> tak obvykle je).
> Viz napoveda k funkci PostThreadMessage
Odpovedá: Erik Salaj
14. 9. 2002 0:14
> OK...
> Vy mate pravdu a ja jsem se mylil.
> Je to tak, thread ma svou frontu zprav. Sorry, mlzim.
nemylis sa, ta fronta sprav je v threade naozaj koli
oknam. Tie okna su dolezite z hladiska fronty sprav
a nie thread. Okno bez fronty sprav nemoze byt,
thread ano. To, ze existuje jedna fronta sprav
pre thread (zdielana viacerymi oknami threadu)
je len optimalizacia (zbytocne by kazde okno
malo vlastnu frontu, ked aj tak thread moze
naraz spracovavat len jednu spravu pre vsetky
okna threadu).
Erik
Odpovedá: Erik Salaj
14. 9. 2002 3:30
> > nemylis sa, ta fronta sprav je v threade naozaj koli
> > oknam. Tie okna su dolezite z hladiska fronty sprav
>
> Ne jen kvuli oknum. Thread muze mit frontu zprav a pritom zadne okno.
no nebol by som si tym celkom isty, citujem z MSDN:
"Because the system directs messages to individual windows
in an application, a thread must create at least one window
before starting its message loop"
Priznam sa, neskusal som to a silne pochybujem, ze existuje
nejaka aplikacia, ktora by mala frontu sprav bez okna.
Teoreticky by to mohlo fungovat, je to ale dosledok
toho, ako je fronta sprav a jej spracovanie threadom
realizovane (teda podla mna rozhodne nie pricina toho).
Ak by fronta bola dolezita pre thready bez okien,
tak zrejme by jej vytvorenie nepodmienovali volanim
user alebo gdi funkcii ale funkcie pre frontu by presunuli
do kernelu.
> > a nie thread. Okno bez fronty sprav nemoze byt,
> > thread ano. To, ze existuje jedna fronta sprav
> > pre thread (zdielana viacerymi oknami threadu)
> > je len optimalizacia (zbytocne by kazde okno
> > malo vlastnu frontu, ked aj tak thread moze
> > naraz spracovavat len jednu spravu pre vsetky
> > okna threadu).
>
> Rekl bych ze dalsim duvodem je predevsim serializace. Ta fronta samozrejme
> neni tak jednoducha jak vypada. Napriklad pro zpravy z klavesnice, kde je
> treba rozhodnout ktere patri jakemu threadu pri prepnuti do okna patrici
> jinemu threadu a podobne.
tazko posudit, zrejme ten efekt z toho, ze by kazde okno malo zvlastnu
frontu (vyhodou by mohlo byt to, ze by svoje spravy mohlo dostat skor
a necakat na spravy inych okien, ktore su pred nim v spolocnej fronte)
nevyvazi urcite problemy, ktore spominas a hlavne reziu s tym spojenu
Erik
Odpovedá: Petr Vones
14. 9. 2002 1:26
From: "Erik Salaj" <winsoft@stonline.sk>
> nemylis sa, ta fronta sprav je v threade naozaj koli
> oknam. Tie okna su dolezite z hladiska fronty sprav
Ne jen kvuli oknum. Thread muze mit frontu zprav a pritom zadne okno.
> a nie thread. Okno bez fronty sprav nemoze byt,
> thread ano. To, ze existuje jedna fronta sprav
> pre thread (zdielana viacerymi oknami threadu)
> je len optimalizacia (zbytocne by kazde okno
> malo vlastnu frontu, ked aj tak thread moze
> naraz spracovavat len jednu spravu pre vsetky
> okna threadu).
Rekl bych ze dalsim duvodem je predevsim serializace. Ta fronta samozrejme
neni tak jednoducha jak vypada. Napriklad pro zpravy z klavesnice, kde je
treba rozhodnout ktere patri jakemu threadu pri prepnuti do okna patrici
jinemu threadu a podobne.
Petr Vones
Odpovedá: Erik Salaj
14. 9. 2002 16:26
> > Priznam sa, neskusal som to a silne pochybujem, ze existuje
> > nejaka aplikacia, ktora by mala frontu sprav bez okna.
>
> viz PostThreadMessage a TServiceThread.Execute/ProcessRequests
(SvcMgr.pas)
otazne teraz je, ci je TServiceThread korektne naprogramovany.
Pozeral som services v MSDN a tato slucka sprav (a s nou
suvisiaca fronta sprav) sa tam vobec nespomina, ale su tam
popisane uplne ine API funkcie urcene pre service applikacie.
Erik
Odpovedá: Petr Vones
14. 9. 2002 3:21
From: "Erik Salaj" <winsoft@stonline.sk>
> Priznam sa, neskusal som to a silne pochybujem, ze existuje
> nejaka aplikacia, ktora by mala frontu sprav bez okna.
viz PostThreadMessage a TServiceThread.Execute/ProcessRequests (SvcMgr.pas)
> Ak by fronta bola dolezita pre thready bez okien,
> tak zrejme by jej vytvorenie nepodmienovali volanim
> user alebo gdi funkcii ale funkcie pre frontu by presunuli
> do kernelu.
Fronta se vytvori i pri prvnim volani GetMessage/PeekMessage (user). Thread v
tomto pripade prejde ze zjednoduseneho modu (bez fronty zprav) do rezimu kdy
ma tuto frontu s cimz je spojena dalsi rezie (vytvoreni struktury THREADINFO a
interni mnozina front).
Petr Vones